JumpingBattle 실시간 랭킹 서비스 기술 의사 결정
JumpingBattle은 동시 접속자 300명 이상을 기준으로 설계된 서비스임과 동시에, 전국 단위 매장에서 방문객들이 실시간으로 자신의 순위를 확인할 수 있어야 하는 환경을 전제로 개발되었습니다.
따라서 단순히 랭킹 데이터를 조회하는 기능보다는, 빠른 갱신 속도와 운영 비용 사이의 균형을 유지하면서도 실제 매장 환경에서 안정적으로 동작할 수 있는 구조를 우선적으로 고려하였습니다.
개요
JumpingBattle은 전국 단위 매장에서 사용되는 서비스였으며, 사용자는 자신의 기록과 순위를 실시간으로 확인할 수 있어야 했습니다.
특히 매장별 랭킹뿐만 아니라 전국 랭킹 역시 함께 제공하고 있었기 때문에, 단순히 데이터를 조회하는 수준을 넘어 다수의 사용자가 동시에 접속하더라도 안정적으로 순위를 전달할 수 있는 구조가 필요하였습니다.
따라서 본 시스템은
- 실시간 데이터 전달
- 빠른 랭킹 조회
- 운영 비용 관리
- 유지보수 용이성
- 정확성
을 주요 목표로 설계되었으며, 실시간 전송 방식과 캐시 구조를 중심으로 기술적 의사결정을 진행하였습니다.
실시간 전송 방식
해당 랭킹 시스템은 WebSocket 기반이 아닌 SSE(Server-Sent Events)를 활용하여 실시간성을 보장하였습니다.
[1]자세한 내용은 동일한 카테고리의 SSE 선택 이유 및 SSE 운영 트러블슈팅 문서에서 별도로 다룹니다.
초기 설계 단계에서는 Polling, WebSocket, SSE를 모두 검토하였습니다.
그러나 JumpingBattle의 랭킹 시스템은 채팅이나 게임 플레이와 같이 양방향 통신이 필요한 구조가 아니었으며, 서버에서 변경된 랭킹 정보를 사용자에게 전달하는 기능이 핵심이었습니다.
또한 전국 단위 매장에서 사용되는 서비스 특성상 실시간성뿐만 아니라 운영 비용과 유지보수성 역시 중요한 고려 대상이었습니다.
따라서 본 서비스에서는
- 서버 → 클라이언트 단방향 전송에 최적화되어 있으며
- 구현 및 운영 복잡도가 상대적으로 낮고
- Polling 대비 불필요한 요청을 줄일 수 있는
SSE 방식을 채택하였습니다.
이를 통해 실시간 랭킹 갱신과 운영 효율성 사이에서 적절한 균형을 유지할 수 있었습니다.
Polling VS SSE
Polling을 사용할 경우 가장 큰 문제는 운영 비용의 증가입니다.
클라이언트는 일정 주기마다 서버에 요청을 전송해야 하며, 실제 데이터의 변경 여부와 관계없이 동일한 요청이 반복적으로 발생하게 됩니다.
특히 JumpingBattle의 랭킹 시스템은 일반적인 게시판과 달리 데이터 변경 시점을 예측하기 어려운 특성을 가지고 있었습니다.
예를 들어 평일에는 오랜 시간 랭킹 변화가 없을 수 있지만, 주말이나 특정 시간대에는 짧은 시간 동안 다수의 기록이 등록되며 랭킹이 연속적으로 변경되는 상황이 발생할 수 있습니다.
따라서 Polling 방식은 동기화 주기를 어떻게 설정하느냐에 따라 실시간성과 비용 사이의 트레이드오프가 발생합니다.
주기를 길게 설정하면 랭킹 반영이 지연될 수 있으며, 반대로 짧게 설정하면 변경이 없는 상황에서도 불필요한 요청이 지속적으로 발생합니다.
반면 SSE는 서버가 데이터 변경 시점에 맞추어 클라이언트로 이벤트를 전송할 수 있기 때문에, 랭킹 시스템의 핵심인 "변경 감지"에 보다 적합한 방식이라고 판단하였습니다.
캐시 구조
캐시를 도입한 가장 큰 이유는 응답 속도 개선보다는 동일한 랭킹 계산의 반복을 줄이기 위함이었습니다.
전국 랭킹은 다수의 사용자가 동일한 데이터를 조회하는 구조였기 때문에, 요청마다 정렬 및 계산을 반복하는 것은 비효율적이었습니다.
따라서 계산이 완료된 랭킹 데이터를 캐시에 저장하고 재사용함으로써 서버 부하를 줄이는 동시에 응답 속도를 개선하였습니다.
또한 SSE 기반 실시간 전송 환경에서도 캐시를 활용함으로써 불필요한 재계산 없이 변경된 데이터를 효율적으로 전달할 수 있었습니다.
배포 구조
실시간 스트리밍 서비스를 AWS Lambda 기반으로 운영하였던 것과 달리, 랭킹 서버는 EC2 환경을 활용하여 운영하였습니다.
가장 큰 이유는 랭킹 시스템이 단순 요청 처리보다는 실시간 연결 유지와 캐시 데이터 재사용의 비중이 높았기 때문입니다.
특히 SSE 기반 구조의 특성상 다수의 사용자가 장시간 연결을 유지하게 되며, 랭킹 데이터 역시 요청마다 새롭게 계산하기보다는 이미 계산된 결과를 재사용하는 것이 효율적이었습니다.
서버리스 환경 역시 검토하였으나, 캐시 데이터와 연결 상태를 지속적으로 유지해야 하는 본 서비스의 특성상 장시간 실행되는 단일 서버 환경이 보다 적합하다고 판단하였습니다.
또한 서버 시작 시 전국 랭킹 및 매장별 랭킹 데이터를 메모리에 적재하여 즉시 응답할 수 있도록 구성하였으며, 이를 통해 반복적인 계산과 데이터 조회를 최소화할 수 있었습니다.
결과적으로 EC2 환경은
- SSE 연결 유지
- 랭킹 캐시 재사용
- 빠른 응답 속도 확보
라는 요구사항을 충족할 수 있었으며, 실시간 랭킹 서비스의 운영 방식과도 가장 잘 부합하는 선택이라고 판단하였습니다.
각주
자세한 내용은 동일한 카테고리의 SSE 선택 이유 및 SSE 운영 트러블슈팅 문서에서 별도로 다룹니다.